Implement pluggable session store and make it threadsafe #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements the pluggable session storage feature, similar to RiveScript-Python PR #32.
The new package
rivescript-go/sessions
defines theSessionManager
interface for managing user variables, and the packagerivescript-go/sessions/memory
implements the default in-memory manager.This changes some of the API functionality. After merging, the library version will be incremented to
v0.1.0
accordingly.The
rivescript.New()
ConstructorThe constructor for
rivescript.New()
has been updated to accept aconfig
object. Example:The "basic" config profile has
Strict=true
and all the other defaults, and the UTF8 profile has that, plusUTF8=true
.Other Functions
SetDepth()
andGetDepth()
now use auint
instead of anint
GetUservars()
andGetAllUservars()
return*session.UserData
objects instead ofmap[string]string
for the user data.ThawUservars()
now takes asessions.ThawAction
instead of a string, with valid values beingThaw
,Discard
orKeep
(all constants in thesessions
package).Thread Safety
This PR will fix #10 because the default
MemoryStore
implementation of theSessionManager
uses a mutex to lock concurrent access to the underlying user data maps.Additionally, a common mutex
rs.cLock
protects map access to global variables, bot variables, substitutions, macro handlers and subroutines when using the API methods to modify these. TODO is to use this mutex when a!Definition
command is parsed or a<bot>
or<env>
tag is handled, but these are edge cases and not a high priority right now.The following Go script verified that the maps are thread safe (this code gave a concurrent read error before implementing this change):